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Foreword 


This year WhiteHat has partnered with strategic partners Coalfire and 
NowSecure to produce the 2018 Application Security Statistics Report. By 
analyzing data from over 15,000 applications, this report provides the most 
comprehensive view of the state of application security available today. 

There is a consistently increasing trend toward the adoption of DevOps 
over the last few years. In 2017, DevOps became a standard practice with 
our combined customer base, with most having one or more active DevOps 
initiatives underway. By embracing DevOps, our customers are able to make 
exponential improvement in innovation and significantly reduce time to 
delivery. As our customers’ innovation partners in Application Security Testing, 
we’re bridging the gap between development, operations and security. 

Development teams are rapidly adopting new technologies and architectures 
to build increasingly complex applications. Software development is as much 
about developing new code as it is embedding third-party components and 
leveraging existing APIs. By working hand-in-hand with operations to automate 
security testing, packaging, and delivery of these applications, application 
development and delivery is now akin to a “Software Production Line”. 

In concert with this trend, application security testing is becoming embedded 
into each phase of the Software Production Line rather than getting bolted 
on at the end. An increasing number of our organizations are recognizing 
application security as a business initiative. They see value in linking 
application security programs to their business impact in terms of increasing 
revenue, decreasing costs, and reducing operational risk. 


WhiteHat Security 2018 Application Security Statistics Report, Volume 13: The Evolution of the Secure Software Lifecycle 


i 




This evolutionary shift toward a secure Software Lifecycle also offers 
tremendous opportunities for comprehensive application testing and hygiene, 
but it reguires a new way of thinking. Consider any of the large-scale breaches 
that grabbed headlines in the last year. We estimate that security was never 
a design consideration or core non-functional reguirement - it was an 
afterthought. As a community, it’s time we orchestrate security into the SDLC. It 
makes good business sense. Universally our web portals, mobile devices, and 
frankly, our lives will be better for it. 

The 2018 WhiteHat Application Security Statistics report explores the 
underlying application security data to derive conclusions, identify trends, and 
highlight what’s working and what’s not when it comes to application security. 
Organizations who have succeeded in improving their security posture in the 
last year have taken a systematic, risk-based approach to evaluating cyber 
security vulnerabilities and addressing these pan-organizationally - as they 
would address any other market-oriented business risk. With these insights, 
business leaders can orchestrate better risk outcomes for their applications 
and their businesses. 


Craig Hinkley Alan Snyder Tom McAndrew 

CEO, WhiteHat Security CEO, NowSecure CEO, Coalfire 
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Why Read This Report 


Apps are the center of 
digital business. 

For many organizations today, applications 
are the foundation of their business. With the 
widespread adoption of Cloud, Microservices 
and APIs, these applications have now grown 
into full-blown inter-operating ecosystems. 
Pinpointing how these new architectures 
impact security is essential, yet remediating all 
vulnerabilities still remains an elusive task. 

Despite their importance, 
apps remain insecure. 

Even though organizations are investing in 
securing the SDLC, teams are falling further 
behind in closing vulnerabilities. According to 
the 2018 Verizon Data Breach Investigations 
Report, web applications were the biggest target 
for data breaches again, more common than 
POS systems or other attractive targets 1 . This 
WhiteHat Security Statistics Report confirms 
that the state of application security, which 
is the biggest target for data breaches, has 
progressively deteriorated year-over-year. The 
two macro indicators of the state of application 
security, namely average number of serious 
vulnerabilities per site and Window of Exposure, 
have trended in the wrong direction over the 
last year. Even as digital transformation reguires 
that software be built faster, application security 
is reguired to reduce your organization’s overall 
business risk. 


Our High-Level Findings 

1. The number of serious 
vulnerabilities continues to increase 
at a rate that makes remediation 
nearly impossible, if teams continue 
to rely on traditional methods. 

2. Microservices are riddled with 
vulnerabilities. In fact, they average 
more vulnerabilities per line of code 
than traditional ones do. That said, 
they do have a higher remediation 
rate and shorter time to fix than 
monolithic apps. 

3. Organizations who embed security 
testing within the SDLC achieve 
significantly better application 
security outcomes than those who 
do not. 

4. Nearly 70% of every application 

is comprised of reusable software 
components. Incorporating Software 
Composition Analysis (SCA) within 
the SDLC enables developers 
to capture these “inherited” 
vulnerabilities early enough to 
prevent them from being introduced. 

5. 85% of mobile apps violated one or 
more of the OWASP Mobile Top 10. 


’Verizon 2018 Data Breach Investigation Report, 11th Edition, page 22. 
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A new, fully-integrated approach is needed. 

This report, the largest and most accurate report focused on application 
security, aims to educate decision makers, security professionals, and 
application developers on how to tackle application security challenges from 
both technological and organizational perspectives. We share how you can take 
advantage of the evolutionary changes within the SDLC to better secure the 
applications at each stage. 

This report is essential reading for executives, security 
practitioners, and development teams who want to better 
understand the present state of software security risk, 
and who seek to benchmark and improve their own 
organization’s performance. 
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Executive Summary 

The Application Security Statistics Report is an annual study. In addition to 
traditional applications, this edition of the report also tracks organizations that 
are achieving economies of scale through Agile development frameworks, 
Microservices, APIs, and Cloud architectures. While these innovations 
have become table stakes for success, they present challenges as well as 
opportunities to secure the applications which are being produced and 
upgraded at an unprecedented pace. 

With the benefit of application security-specific data, this report provides an 
analysis of the state of application security, brings to the forefront evolutionary 
trends in secure application development, and highlights best practices that 
result in better application security over time. 


Here are the key takeaways: 

1. The number of serious application security vulnerabilities continues to 
increase at a rate that makes remediation nearly impossible, if teams 
continue to rely on traditional methods. 

2. Microservices are riddled with vulnerabilities. In fact, they average more 
vulnerabilities per line of code than traditional applications do. That said, they 
also have a higher remediation rate and shorter time to fix than monolithic apps. 

3. Customers who embed security testing within their development process 
achieve significantly better application security outcomes than those who do not. 

4. Nearly 70% of every application is comprised of reusable software 
components (e.g. third-party libraries, Open Source Software (OSS), etc.). 
Incorporating Software Composition Analysis (SCA) into the development 
process enables developers to capture these “inherited” vulnerabilities early 
enough to prevent them from being introduced. 

5. 85% of mobile apps violated one or more of the OWASP Mobile Top 10. 
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The number of serious vulnerabilities continues to increase 
at a rate that makes remediation nearly impossible, if teams 
continue to rely on traditional methods. 

We are discovering more vulnerabilities per site per year. While this unsettling 
statistic may suggest that teams aren’t doing a great job at securing their 
applications, the increasing number of serious vulnerabilities can be attributed 
to an ever-expanding risk surface area coupled with an ever-expanding set of 
serious vulnerabilities that we are looking for. Additionally, as more organizations 
embrace agile DevOps processes, more applications are being released 
faster than ever. The guicker applications are released, particularly those that 
are comprised of reusable components, the faster more vulnerabilities are 
introduced. 

Our statistics find that the risk surface area is expanding as the volume of 
attacks continues to increase, the attacks themselves are becoming more 
sophisticated, and the security chasm (both skills and resources) across the 
SDLC continues to increase. In addition, enterprises are expanding the scope of 
the apps they’re assessing each year. 

The net effect is that serious vulnerabilities continue to increase at a 
rate that makes remediation nearly impossible, if teams continue to 
rely on traditional methods. 


Microservices are riddled with vulnerabilities. In fact, 
they have average more vulnerabilities per line of code 
than traditional ones do. That said, they do have a higher 
remediation rate and shorter time to fix than monolithic apps. 

As Sam Newman, author of O’Reilly’s Building Microservices notes, 

“Done right, and microservices can increase the security of your vital 
data and processes. Done wrong, and you can increase the surface 
area of attack.” 
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Experience tells us that it is easier to assess and secure smaller components. 
Since individual microservices are orders of magnitude smaller than a traditional 
monolithic app, the logical conclusion should be that there would be fewer 
vulnerabilities introduced into microservices and that they’d be easier to fix. 
We’ve examined vulnerabilities and their remediation rates within microservices 
compared against traditional, monolithic apps, and our findings suggest this is 
only half true. 

I More, not fewer, vulnerabilities are introduced, but they are fixed 
faster and at higher rates. 


Organizations who embed security testing within the SDLC 
achieve significantly better application security outcomes 
than those who do not. 

By using DAST and SAST technigues in combination, teams can gain a better 
foothold in tackling the growing set of vulnerabilities. DAST enables teams to 
view vulnerabilities in a larger, more accurate context by assessing a running 
application in an environment that is close/identical to the final operational 
environment, thus enabling higher accuracy of vulnerability detection. As a 
result, teams are able to prioritize their mitigation and remediation efforts. 

By incorporating SAST testing during the early phases of the SDLC, teams 
can detect vulnerabilities as early as possible to make remediation guicker 
and less expensive. Furthermore, SAST testing can uncover certain kinds of 
vulnerabilities that may be present but undetected by DAST. A good example is 
Content Spoofing. This underlying code-level vulnerability could be present, but 
it may only be detectible via SAST methods due to browser-level protections. 

By combining both scanning types, organizations can reduce costs 
and uncover hidden risks, as well as empower developers to fix 
problems earlier in the process. 
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Nearly 70% of every application is comprised of reusable 
software components. Incorporating Software Composition 
Analysis (SCA) within the SDLC enables developers to 
capture these “inherited” vulnerabilities early enough to 
prevent them from being introduced. 

The “bolt-on” approach of identifying vulnerabilities inherited with the inclusion 
of third party libraries (both open-source and commercial) after the applications 
are built and then trying to find a way of remediating them without impacting 
operations isn’t scalable. “Inline” SCA, that is integrated with the development 
process, is a far more sustainable practice and brings yet another key 
application security assessment capability to developers. 

With the increased visibility offered by inline SCA, developers avoid 
the disruption, cost, and effort associated with patching applications 
in production. 


85% of mobile apps violated one or more of the OWASP 
Mobile Top 10. 

Overall, a highly concerning 85% of mobile apps violated one or more of the 
OWASP Mobile Top 10. An astonishing number of mobile apps returned risk 
findings for insecure data storage and/or insecure communication, client code 
guality issues and vulnerabilities, risk exposure to reverse engineering, and/or 
extraneous functionality that could potentially be exploited. 
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WhiteHat’s Methodology 

WhiteHat Security has been publishing this report since 2006. The study comprises statistical 
data and analysis gathered from continuously updated security testing information in WhiteHat 
Sentinel, a cloud-based application security platform. 

The aggregated data comes from actual code-level analysis of over 225 billion lines of code 
and over 15,000 thousand applications. Sentinel inspects the full spectrum of applications 
including components and shared libraries. Industry information for websites and applications 
is provided by customers. 

The report's statistical analysis focuses exclusively on assessment and remediation data for 
custom applications. Data is segmented along multiple dimensions including vulnerability 
risk levels, vulnerability classes, and industries. Data analysis uses key indicators that include 
the likelihood of a given vulnerability class, remediation rates, time to fix, and age of open 
vulnerabilities. 

• Risk levels are based on the rating methodology of Open 
Web Application Security Project (OWASP). 

• Vulnerabilities are rated on five levels of risk - Critical, High, 

Medium, Low and Note. 

• Critical and high-risk vulnerabilities taken together are 
referred to as “serious” vulnerabilities. 

• Vulnerability classes are based on the threat classification of 
Web Application Security Consortium (WASC). 

Coalfire’s Methodology 

Coalfire offers a broad set of cybersecurity services, including penetration testing. Coalfire 
penetration tests leverage vulnerabilities identified in WhiteHat solutions and provide insights 
on the exploitability of vulnerability combinations. Coalfire pen tests also evaluate the overall 
security model and demonstrate risks. Coalfire employs a series of automated tools along with 
manual exploitation methods to actively exploit vulnerabilities in a non-harmful manner. 

NowSecure’s Methodology 

The NowSecure benchmark analyzed 45,000 public apps posted to Apple App Store and 
Google Play, across a broad distribution of app categories, developed by vendors and 
businesses small and large around the world, including Fortune 500 and Global 2000 
organizations. The NowSecure platform automatically downloads and tests third party app 
binaries using a complete multi-pass approach of static, dynamic and behavioral tests on 
real mobile devices. This automated, multi-pass approach uses an attacker point of view to 
yield very thorough and highly accurate risk results. All risk findings are graded using industry 
standard CVSS scores and mapped to OWASP Mobile Top 10. 
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Dynamic Application Security 
Testing - DAST 

Dynamic Application Security Testing (DAST) is an essential part of any 
application security program. By testing running applications (in production and 
pre-production environments), organizations get an accurate window into the 
true risk surface area of these applications. The collective view this data offers 
demonstrates that there is still much room for improvement. 


Vulnerabilities by Industry 


2017 Vulnerabilities per DAST site by Industry 

Across all major industries, the number of serious vulnerabilities per site has 
increased, with a few exceptions. 
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OBSERVATION 1: 

The number of serious vulns per site has gone up year over year. 

These statistics tell a very scary story. AppSec and DevOps teams are 
stuck in Sisyphean cycle of pushing against an insurmountable mountain of 
vulnerabilities. No matter how hard they push, new vulnerabilities are discovered 
faster than they can fix them. 


OBSERVATION 2: 

Finance, Retail and Healthcare are showing fewer serious vulnerabilities 
per site (compared to last year). 

All that bad press for some of the largest banks, retailers, and healthcare 
providers in the previous year has had an effect. The number of serious 
vulnerabilities per site has gone down for these industries, suggesting that their 
investments in AppSec are paying off. 
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Window of Exposure 


2017 Window of Exposure (from DAST) 



OBSERVATION 1: 

The Window of Exposure (WoE) across all industries remains the same: Too 
long. 

Teams continue to focus on fixing easy-to-patch medium and lower-severity 
findings when a smarter tactic would be to focus on repairing the most serious 
vulnerabilities. 


OBSERVATION 2: 

Despite some improvement, the WoE for the serious vulnerabilities in 
Finance, Retail, and Healthcare remains high. 

Even though the number of serious vulnerabilities per site has shrunk for these 
industries, the WoE remains a high risk. 
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Vulnerability Likelihood by Class 


2017 DAST Vulnerability Likelihood 

The top 4 most likely DAST vulnerabilities are similar to last year: Information 
Leakage (45%), Content Spoofing (40%), Cross Site Scripting (38%), and 
Insufficient Transport Layer Protection (23%). 
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OBSERVATION 1: 

Information Leakage has increased by 8 percent since last year’s report. 

The rate of adoption for new frameworks in applications continues to rise, 
leading to more information leakage errors. Developers are keen to start 
using new frameworks, but they’re not motivated to dig deep into the 
documentation reguired to configure these frameworks for secure use. In the 
meantime, our testing technigues for Information Leakage Errors continues to 
improve, thus resulting in a higher number of these findings. 

By default, a large number of libraries leak information if not specifically 
configured to avoid this practice. Organizations are consistently choosing 
to implement bespoke - rather than framework - or platform-provided error 
handling, leading to increased information leakage errors. 


An interesting change 
is that Content Spoofing 
and Cross Site Scripting 
(XSS) have swapped their 
positions from last year, 
with Content Spoofing 
edging out XSS this year. 
This could be attributed 
to new browser security 
settings that hide XSS 
vulnerabilities, highlighting 
the need to combine 
DAST+SAST strategies in 
your AppSec program to 
catch issues suppressed 
by newer client-side 
controls. 


OBSERVATION 2: 

Transport Layer Security (TLS) continues to be an operational challenge. 

Even if sites are perfectly configured for TLS best practice today, new TLS 
vulnerabilities continue to be discovered. 

Computationally it is now easier to break weak encryption, and 
new vulnerabilities specific to encryption continue to be found. 

As a result, exploiting vulnerable encryption libraries is a popular target 
of choice for hackers. Because TLS libraries are application functionality 
agnostic, their vulnerabilities are too. The increasing number of sites using a 
vulnerable version of a TLS library provides a convenient target for hackers. 

The most frustrating part about TLS vulnerabilities is that even if you’re 
doing everything else right, it’s easy to get TLS wrong. And, unlike other 
vulnerabilities, remediation strategies for TLS vulnerabilities are always 
changing to match new TLS and encryption attack vectors. 
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Remediation Rates by Risk Level 


2017 DAST Remediation by Risk 
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OBSERVATION 1: 

Overall remediation rates have gone down year over year (YoY.) 

Considering we are discovering more vulnerabilities per site than ever before, 
it’s not surprising to see that remediation rates are suffering as a result. One can 
only apply so many fixes and patches in narrow operational windows, especially 
in production systems that are expected to be “always-on”. 


OBSERVATION 2: 

YoY vulns/site has gone up -*• folks are still focused on critical -► drop in highs. 

While the remediation rates by risk level haven’t changed dramatically YoY, we 
are seeing that only critical and low issues are being resolved guickly, compared 
to the other risk categories. While teams that are using DAST and SAST have 
more traction in remediating high and medium vulnerabilities, they’re still not 
fixing these issues before new vulnerabilities are discovered. This backlog makes 
it nearly impossible for teams to achieve or maintain a good security posture. 


OBSERVATION 3: 

Organizations’ remediation strategies are failing. 

Organizations usually develop policies and SLAs to drive their security 
programs. We would expect to see that critical and high vulnerabilities have 
the highest remediation rates and for the rate to fall as the risk level goes 
down. Instead, while we do see critical vulnerabilities are the most remediated, 
the high-, medium-, and low-risk vulnerabilities do not have substantially 
differentiated remediation rates. 
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Remediation Rates by Vulnerability Class 

2017 DAST Remediation Rates by Class 
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OBSERVATION 1: 

Application Code Execution exploits made it into the headlines (e.g. 
Expression Language Injection in Struts and Spring) in 2017, and as a result 
were remediated with urgency. Because controls for HTTP Response splitting 
have built in to newer versions of J2EE, PHP, and other popular languages 
and frameworks, this remediation rate has likewise been very high. At the 
other end of the spectrum, weak ciphers, directory traversal attacks, and OS 
command injection are still slow to be updated and fixed, perhaps due to the 
lack of media attention and high-profile hacks using them. 


OBSERVATION 2: 

Remediation rates for SQL Injection has fallen significantly (by ™10%) even though 
the reputation damage and data loss damage due to SQL Injections is significant. 

This is in part due to the heightened focus and resource allocation to remediate highly 
publicized zero-day branded vulnerabilities - even though some of these are lower-risk 
vulnerabilities. Vulnerabilities that have a fancy name, logo, and website get fixed more 
often - even if they’re not as risky. Despite the fact that SQL injection remediation rates are 
getting worse and the conseguential reputation damage and data loss damage costs are 
higher than ever, these aren’t being remediated at nearly the rate of “branded” vulnerabilities. 


Time-to-Fix by Risk Level 

2017 DAST Time-to-Fix by Risk 



OBSERVATION: 

It’s remarkable how high time to fix (TTF) is. In fact, 
TTF has gone up for all risk levels except Medium. 

Development teams are fixing critical and medium risk 
vulnerabilities faster than the other categories, but 
not before we find more through constant scanning. 
Teams are overwhelmed balancing the workload 
of new feature development while reacting to the 
security gaps found in the features that they have 
already deployed. With organizations adopting 
security testing earlier within the development cycle, 
the time to fix for SAST vulnerabilities is getting better 
and DAST vulnerabilities are languishing. 


18 


WhiteHat Security 2018 Application Security Statistics Report, Volume 13: The Evolution of the Secure Software Lifecycle 








Static Application Security 
Testing - SAST 

Vulnerability Likelihood by Class 

2017 SAST Vulnerability Likelihood by Class 
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OBSERVATION 1: 

Unpatched libraries remain the most common vulnerability class. 

Given breaches like the one that hit Equifax, it’s not surprising that unpatched 
libraries have become one of the highest priority issues for our customers. 
Customers who have implemented one or both of the following practices are 
seeing much better outcomes. 
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1. DevOps - Testing earlier in the SDLC allows security to help developers identify weak 
(unpatched) libraries and platforms while still in development, which in turn allows fewer 
vulnerabilities to go live in production. The ability to automatically run a suite of unit, functional, 
and end-to-end tests allows developers to keep their libraries up to date without spending hours 
of research to determine if a version change breaks application functionality. If the tests pass, the 
upgrade is released; Only when they don't pass does an upgrade effort need to be allocated. 

2. Robust Centralized Package Management - The three cardinal rules of packet management: 
a. doesn't trust the repository; b. the trusted entity with the most information should be the one 
who signs; and c. don't install untrusted packages. Engaging a central package management 
system allows fewer untrusted sources, out-of-date libraries into code, and creates a repeatable, 
testable package distribution system. 


WhiteHat SAST customers use inline Software Composition Analysis (SCA), which makes it 
easier to find and identify out-of-date third-party libraries and platforms. Inline SCA scanning 
embedded within SAST can help educate developers about the internal dependencies of 
inherited and legacy projects and code. Good security hygiene and patching processes 
combined with an agile DevOps approach are the keys to success. 


COROLLARY 1: 

The broader challenge of updating these libraries still poses a challenge of time and 
dependencies on the organization, as well as developer’s lack of expertise on engineering a 
solution. In fact, unpatched libraries are the second most popular topic for submitted inguiries 
to the WhiteHat Security Threat Research Center (after Cross-Site Scripting guestions.) 


COROLLARY 2: 

Despite the high number and ranking of Unpatched Libraries in our SAST data, we’d like to 
highlight the continued importance of Information Leakage as well. Even though Information 
Leakage may not be accurately discovered using SAST testing, it can easily be introduced as 
a by-product in an app. Additionally, Information Leakage is difficult to pinpoint in SAST scans 
and is difficult to remediate. As a result, it’s often de-prioritized or missed altogether, which is 
why DAST is an essential partner for SAST. 


OBSERVATION 2: 

SQLi and XSS still remain persistent, pointing to the general lack of developer 
knowledge of secure development. 

Developers are spending a lot of time fixing found vulnerabilities but are not taking the necessary 
architectural and software design steps reguired to avoid these vulnerabilities in the first place. 
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Remediation Rates by Risk Level 


2017 SAST vs. DAST Remediation by Risk 

Prioritization remains a challenge with development teams not prioritizing high 
vulnerabilitiess when it comes to SAST. DAST remediation prioritization reflects 
the seriousness of the vulnerabilities. 




MEDIUM 



56.8% 




0% 10% 20% 30% 40% 50% 


DAST 

SAST 


60% 70% 


80% 


OBSERVATION: 

Developer education and enablement about vulnerabilities in tandem with 
accurate identification leads to better outcomes. 

Developers do not like to waste time. With source code testing and analysis, 
accurate data and good education drive developer behavior for remediation. 
Generally, 2017 was a year of education in organizational priority. With over 
5,000 developer registrants in WhiteHat’s Certified Secure Developer program 
as well as eLearning modules, DevOps teams are actively engaging in training 
and certification on remediation for common source code vulnerabilities. 
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Remediation Rates by Vulnerability Class 

2017 SAST Remediation Rates by Class 
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OBSERVATION 1: 

Remediation rates for Insecure Data Storage vulnerabilities, Information Leakage 
vulnerabilities and Disclosure vulnerabilities remain low - thus creating eventual 
non-compliance in applications when it comes to Pll and data security. 


OBSERVATION 2: 

In 2017 vs. 2016, developers were more effective at remediating popular 
source code-based injection style vulnerabilities like SQLi, XSS, Path Traversal, 
URL redirector abuse. This is encouraging, as these remain some of the top- 
used attack vectors to compromise a web application, and clearly shows the 
effectiveness of SAST scanning prior to pushing apps into production as part of 
risk reduction. 
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OBSERVATION 3: 

Secrets management still remains a challenge for developers. 

With GDPR and other regulations being implemented in the last 12 
months, we’re curious to see how the mandate for Privacy by Design 
and Secrets Management will trickle down to developers, as well as 
to AppSec and DevOps teams. 

Vulnerabilities related to Secrets Management and data storage have significant 
impact on data privacy governance and compliance. Because of this and other 
legislation being written around the world for compliance guidelines, teams 
will likely need to get broader and higher organizational buy-in to get these 
remediated. Established patching, remediation, and escalation procedures as 
well as security checklists are essential in order to drive action and compliance 
across the enterprise. 
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Mobile Application Security 
Testing 

Top 2017 OWASP Mobile Risks by Category 



Insecure Data Storage 

Half of all mobile apps tested violated the OWASP Mobile Top 10 for Insecure 
Data Storage. Tests for data storage risks include data leakage in local files 
and system logs, client-side injection and weak server-side controls. Critical 
data examined included account credentials, PI I, email address, geolocation, 
IMEI, serial number, WIFI info, and more. Overall, Android apps had higher rate 
of violations than iOS mobile apps, with a shocking 52 percent of Android 
apps surfacing the “world writable executable” vulnerability. With the rise of 
strong privacy regulations like GDPR and the increasing potential for remotely 
accessible attacks, organizations should inspect mobile apps for privacy and 
protection of critical data. 
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Insecure Communication 


Nearly half of all mobile apps tested violated the OWASP Mobile Top 10 for 
Insecure Communication, which leaves those mobile apps susceptible to man in 
the middle (MITM) attacks. Tests for insecure communication risks include SSL/ 
TLS/Cert issues, poor handshake and HTTP transfer of data in clear text. Critical 
data examined includes account credentials, Pll, email address, geolocation, 

IMEl, serial number, WIFI info, and more. A surprising 30 percent of iOS mobile 
apps use insecure HTTP (not HTTPs) and more than 50 percent of iOS mobile 
apps do not use the recommended Application Transport Security (ATS) method 
for secure encrypted communications. Given the more highly exploitable MITM 
communications risks that do not reguire hands on the device and strong 
privacy regulations, including GDPR, organizations should consider carefully how 
employee and customer data is being protected in transmission. 


Insecure Authentication and Authorization 

Authentication and authorization are shining areas of secure app development, 
where very few mobile apps across the test group had risks with CVSS- 
scored vulnerabilities. Authentication tests for risks such as improper identity 
management and weak session management, while Authorization tests for risks 
such as improper local authentication and forced browsing. Organizations can 
be more confident of access control and protection across most mobile apps. 


Code and Implementation Issues 

Code and implementation issues are predominantly found with Android Apps. 
While all Apple apps are automatically protected via DRM, 62 percent of Android 
apps are either not- or improperly-obfuscated leaving them exposed to reverse 
engineering from attackers. 82 percent of Android apps allow backup which 
may lead to data loss (although for most apps the user can configure to disable 
this feature.) Additional risk findings of Android apps include 1465 allow arbitrary 
code execution, 1133 allow SQL injection and 112 have debug flag on. In addition, 
numerous mobile apps exhibited vulnerabilities due to insecure third party 
libraries. 

Organizations at a minimum should disable allow backup in their mobile apps 
that contain employee and customer data, and otherwise inspect all mobile 
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apps for risks of data leakage and other vulnerabilities. App developers on 
Android should strengthen their obfuscation. 


Mobile Security Recommendations 

Our analysis shows substantial and freguent risks of data leakage in device 
storage, in communication and within coding practices themselves. All 
organizations must take into consideration the security risks in the mobile apps 
they build, buy and download. We recommend the following best practices to 
help address some of the significant mobile findings identified in 2017: 

• Assume all third party mobile apps found in app stores are untrusted until 
validated — no matter who the developer is. 

• Put controls in place to analyze and monitor third party mobile app risk, 
including tracking inventory. Adapting business processes to include a 
risk analysis program and use automated tools for in-depth testing and 
continuous monitoring. 

• Given that mobile operating systems, architecture, development tools, 
and developer roles are significantly different from traditional web and PC 
applications, more specialized training and AppSec testing tools are reguired 
for secure mobile app development. 
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The Evolution of the Secure 
Software Supply Chain 


The first step on the AppSec journey is to use DAST data to get a lay of the land. 
What is the risk surface area of my applications? Where are my vulnerabilities? 
Which of these vulnerabilities can be fixed easily - without impacting 
operations? Which reguire more analysis, consensus, and escalation? What are 
the impacts of leaving these vulnerabilities exposed? How long is too long to 
leave these vulnerabilities open? So many guestions add to noisy confusion. 

You can turn the noise volume down significantly by introducing SAST into the 
SDLC. By giving developers code-level visibility into security analysis, they 
become part of the solution, and learn their key role as security stewards of 
the organization. Their part in securing the SDLC supply chain becomes much 
clearer, especially when compared to only looking through the lens of the 
penetration tester or hacker with skills (which is what DAST gives you.) 

The next phase on the AppSec evolutionary journey is educating developers 
on how to build applications that are secure by design. Focused, outcome- 
based training like WhiteHat’s Certified Secure Developer Program (WCSD) 
teaches developers to write secure code while maintaining agility, speed, and 
performance to keep pace with business goals. This effort, along with combining 
DAST and SAST methodologies, can help organizations achieve effective and 
long-term risk and cost reduction. 

With the rise of Microservice architecture, embedding security into the SDLC is 
essential. As our data shows, it’s nearly impossible to gain any traction by relying 
on reactive, “bolted-on” security approaches. 
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Using DAST & SAST in Combination 

The two metrics to track a successful implementation of DAST and SAST in 
combination are the rate of introduction of serious vulnerabilities and time 
to fix. With the appropriate implementation of DAST and SAST within an 
organizations SDLC, both these metrics should trend downwards. 


Serious Vulnerabilities O B S E R VAT ION: 

Introduced per Month 

Organizations saw a 50 percent drop in 
new production vulnerabilities identified 
in DAST after the introduction of SAST 
into the application security program. 

Nothing can replace having a constant up-to-date 
snapshot of the current production web application 
security risks. However, adding SAST scanning 
to the DAST discipline reduced the findings by 
half, saving money and resources by identifying 
problems in development rather than production. 

OBSERVATION: 

Organizations saw a 25 percent drop in 
time-to-fix after the introduction of SAST 
into the application security program 

As organizations mature to incorporate SAST 
and DAST in tandem, they naturally align the 
application security program with the SDLC - 
thus making application security a component 
of the SDLC rather than an afterthought. With 
this alignment, development teams can address 
application security issues a part of their normal 
daily responsibilities. With SAST, development 
teams get rapid feedback as they code, allowing 
them to research findings and get address application security issues in a 
planned and systematic manner. As the integration of SAST and DAST into 
the SDLC matures further, organizations should expect to see a decreased 
time to fix. 


Average Time 
to Fix in Days 


122.42 



Before After 

First SAST First SAST 


0.87 



Before After 

First SAST First SAST 


PRO-TIP 

Integrate both DAST and 
SAST vulnerabilities into 
your development queues. 
Treating DAST and SAST 
vulnerabilities as regular 
software quality defects 
will allow development 
teams to create a 
systematic plan to address 
not only the vulnerabilities, 
but also the root-cause 
of those vulnerabilities 
- many times resulting in 
an architecture update 
to prevent further 
occurrences. 
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Microservices Application Security 

Microservices present a higher volume of application security vulnerabilities per 
line of code compared to traditional monolithic applications, yet remediation 
rates are higher, and fixes are faster. 


Vulnerabilities per OBSERVATION 1: 

100K Lines of Code ... . „ . 

Microservices have more vulnerabilities per line 

180 of code than traditional applications. 

Smaller isn’t necessarily better when it comes 
to the number of vulnerabilities overall. This 
observation is consistent with findings in the 
2018 Verizon Data Breach Investigation Report 
(DBIR), which found that small, modularized, web 
Traditional Microservice applications contain just as many vulnerabilities 

as large ones 2 . It is challenging to map a 
propagation of trust model in terms of the communications architecture, i.e. how 
each microservice talks to the others, how data is exchanged across these 
services, what protocols are allowed, and how do we validate authorization and 
identification, etc. Often, the only way to determine this trust model is to wait 
until the app is in production. This, combined with the high rate of unpatched 
third-party libraries in use, makes for a perfect storm of insecure applications. 



Average OBSERVATION 2: 

Remediation Rate . . ...... 

The remediation rate is higher for microservices 

54% app than traditional applications. 

47 % 

While microservices present a higher volume of 
application security vulnerabilities, we observed 
that the remediation rate of these vulnerabilities is 
much higher. 

Microservices-based apps are attractive mainly 
based on their modular nature. The beauty of 
modular architectures is you can rip and replace functional components without 
worrying about potentially re-factoring/re-architecting the entire application. 



2 2018 Verizon DBIR, 11 th Edition, page 65. 
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OBSERVATION 3: 

The time to fix for vulnerabilities found in 
microservices is 50% lower than traditional 
applications. 

There are less HIGH and MED vulns in 
microservices apps vs. monolithic ones (which 
suggests that the HIGH and MED vulns in 
monolithic apps don’t get the attention they 
need because no one wants to “break the 
Frankenstein.” Remediating issues found in 
microservices apps is much less complex, which could explain why there 
are fewer in these categories compared to traditional, monolithic apps. 
Additionally, the time to fix (TTF) for microservices is significantly faster than 
vulnerabilities found in monolithic apps. And this makes sense, in fact, this 
observation says less about code and more about the people dealing with 
it (an organizational artifact vs. a software-based one.) 


Average Time-to-Fix 

95 Days 

43 Days 

Traditional Microservice 


PRO-TIP 

Execute DAST on your 
microservices apps in 
production because it's 
the only way to know 
which vulnerabilities will 
become manifest once 
the components are 
integrated. While SAST can 
evaluate the security of 
each of the components 
on its own, only DAST can 
give you the full, real-world 
picture. 


Microservices... A double-edged sword? 

One breach in a monolithic application can affect all components. In a 
Microservices app, we can use segregation and apply defense-in-depth 
in various different applications and integration points. That said, these 
have greater risk surface area, they combine “polyglot” environments, they 
often repeatedly use third party unpatched libraries, all of which complicate 
security protocols and increase risk. 
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Software Composition Analysis - SCA 

Organizations are increasingly adopting open source and commercially off- 
the-shelf components to auger rapid innovation and faster time to delivery 
for applications. 

Consequently, the number of “inherited vulnerabilities” has risen 
significantly as evidenced by the fact that Unpatched Library 
Vulnerabilities are the most likely vulnerabilities by far (21 
percent.) 

By incorporating Software Composition Analysis within the SDLC, WhiteHat’s 
customers have increased visibility and awareness about the existence 
of these “inherited” vulnerabilities. Development and DevOps teams are 
prioritizing action on these vulnerabilities as is seen by the spike in the 
number of specialist inguiries seen by the Threat Research Center to learn 
more about “Unpatched Library” vulnerabilities and strategies to remediate 
them. 

Nearly 20 percent of the inquiries answered by the Threat 
Research Center are around Unpatched Libraries - almost on 
par with Injection vulnerabilities. 


PRO-TIP 

Incorporate Software 
Composition Analysis 
into the SDLC, including 
during development and 
packaging. Doing so 
will allow development 
and DevOps teams to 
create a systematic 
plan to update open 
source and commercially 
off-the-shelf libraries 
during development, 
linking, packaging and 
deployment. 


Ask-o-Question by Percentage 
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Conclusion: How to Achieve 
Evolutionary Change in 
Application Security 


“The Evolutionary Levels of SDLC Maturity” 

LEVEL 1: RISK DISCOVERY AND MANAGEMENT 

A phased approach to implementing appsec into the 
SDLC and monitoring the right set of metrics results in a 
sustainable and scalable approach to implementing app 
security within. 


In this activity, the organization is focused on discovering exploitable risks in 
the application in its current released state. The findings will contribute to the 
organization’s top line risk metric for the application. They will also form the 
basis of comparison and analysis for the purpose of planning and prioritizing 
remediation initiatives, as well as providing the canonical data model for release 
assurance and developer enablement activities. 

PRO-TIP 

Incorporate DAST to discover risk and use the following application security 
statistics as key performance indicators to measure your success over time: 

1. Window of Exposure: The “Window of Exposure” metric provides a 
baseline for your industry to track the period of exposure of applications to 
application security risks. Develop an SLA for “Window of Exposure” for your 
organization and aggressively try to reduce it for all your applications. 

2. Time to Fix by Risk: The “Time to Fix by Risk” metric provides an industry 
baseline for how long it takes to fix a vulnerability and associates that with Risk 
(to the business). Develop an SLA for “Time to Fix by Risk” for your organization 
and aggressively try to reduce it for vulnerabilities in your applications. 
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LEVEL 2: RELEASE ASSURANCE 


In this activity, the organization aims to ensure that a new release candidate 
does not add additional risk compared to the application’s current release. 
Additionally, the organization aims to ensure that remediation activities have 
been successful in reducing the application’s risk profile. The release assurance 
concern is an ideal place to integrate portions of the assessment methodology 
into the release pipeline and is most successful when combined with a pre¬ 
existing and robust risk discovery program. 

PRO-TIP 

Integrate DAST and SAST Into your Software Lifecycle and leverage the following 
application security statistics to baseline your organizations “Release Assurance" 
strategy: 

1. Average Time to Fix: The “Average Time to Fix” metric provides an industry 
baseline for how long it takes to fix a vulnerability in general. Develop an 
SLA for “Average Time to Fix” for your organization and aggressively try to 
reduce it for all vulnerabilities. 

2. Vulnerability Likelihood by Class (SAST): Organizations are increasingly 
adopting open source and commercial off-the-shelf components to rapidly 
innovate. As such, the likelihood of inheriting vulnerabilities is higher than 
ever before. Baseline your development teams’ security goals by creating an 
SLA around reducing the most likely vulnerabilities by class. 
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LEVEL 3: DEVELOPER ENABLEMENT 


Educate and empower developers throughout the SDLC, 
add AppSec tools to the developer workspace 


In this activity, the organization aims to reduce the number of vulnerabilities 
developers are introducing into the release pipeline by bringing assessment 
and education into the workspace of the developer. Developers are provided 
with lightweight application security tools that can be run in the developer’s 
own sandbox to eliminate security issues before they are committed to version 
control or the release pipeline. Education is conducted based on the common 
findings of the risk discovery and release assurance, secure enterprise libraries 
are developed to replace commonly used components that are prone to misuse, 
and a guestion and answer feedback loop is established via integrated security 
knowledge bases or direct interaction with application security experts. 

PRO-TIP 

Focus on training for staff based the following application security statistics to 
drive your organization's “Developer Enablement" strategy: 

1. Vulnerability Likelihood by Class (DAST and SAST): Use the “Vulnerability 
Likelihood by Class” (for both DAST and SAST) from this report to setup 
focused and recurring training for your development, operations and security 
teams. Track your teams’ progress by tracking Vulnerability Likelihood by 
Class for the applications they develop and evolve your training efforts to 
meet the evolving needs of your teams. 

2. DAST and SAST Remediation by Risk: Use the “DAST and SAST 
Remediation by Risk” metric to baseline your teams’ goals. Develop SLAs 
and procedures/training to support the SLAs that promote remediation 
efforts by taking a risk-based approach. Track the “DAST and SAST 
Remediation by Risk” metrics to see that the most serious vulnerabilities are 
being prioritized for remediation. 
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Appendix: Glossary of Terms 


Web Application Vulnerability Classes 

ABUSE OF FUNCTIONALITY 

Abuse of Functionality is an attack technique that uses a web site's own features and 
functionality to attack. It misuses an application's intended functionality to perform an 
undesirable outcome. These attacks can consume resources, circumvent access controls, or 
leak information. The potential and level of abuse will vary from site to site and application to 
application. This category of attacks is broad and includes situations where an application's 
features can be functioning properly but still be exploited. 

APPLICATION MISCONFIGURATION 

Application Misconfiguration exploits configuration weaknesses found in applications. Many 
applications come with unsafe features enabled by default, such as debug and QA features. 
These features may provide a means for a hacker to bypass authentication methods and gain 
access to sensitive information, perhaps with elevated privileges. 

BRUTE FORCE ATTACK 

Brute Force Attacks are used to determine an unknown value such as a password by using 
an automated process to try many possible values. The attack takes advantage of the fact 
that the entropy of the values is smaller than perceived. For example: while an 8-character 
alphanumeric password can have 2.8 trillion possible values, many people will select 
passwords from a much smaller subset consisting of common words and terms. 

BUFFER OVERFLOW 

Buffer Overflow is a flaw that occurs when more data is written to a block of memory, or buffer, 
than the buffer is allocated to hold. Exploiting Buffer Overflow allows an attacker to modify 
portions of the target process address space. 

CONTENT SPOOFING 

Content Spoofing is an attack technique that allows an attacker to inject a malicious payload 
that is later misrepresented as legitimate content of an application. This attack compromises 
the trust relationship between the user and the application. 
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CREDENTIAL / SESSION PREDICTION 


Credential or Session Prediction is a method of hijacking or impersonating an authorized 
application user by deducing or guessing the unigue value that identifies a particular session 
or user, which can allow attackers to issue site reguests with the compromised user's 
privileges. 

CROSS SITE REQUEST FORGERY 

Cross-Site Reguest Forgery is an attack that involves tricking a victim into sending an HTTP 
request to a target destination without the victim's awareness, so that the attacker can perform 
an action as the victim. CSRF exploits the trust that an application has for a user. 

CROSS-SITE SCRIPTING 

In Cross-Site Scripting attacks, a malicious site includes a particular URL - one that will cause 
the target site to include a script chosen by the malicious site - in a target site's page, and 
makes the user agent request it. Since the page is loaded with the user agent's credentials, 
the script is able to perform actions at the target site in the user's name. 

CRYPTOGRAPHY: INSECURE DIGEST 

Insecure Digest refers to an application that utilizes an insecure cryptographic hashing 
algorithm. The potential consequences of using an insecure cryptographic are similar to using 
an insecure cryptographic algorithm: data theft or modification, account or system compromise, 
and loss of accountability - f.e., non-repudiation. 

DENIAL OF SERVICE 

Denial of Service and Distributed Denial of Service (D/DoS) attacks attempt to prevent an 
application from serving normal user activity. DDoS attacks, which are normally applied to the 
network layer, are also possible at the application layer. These malicious attacks can succeed 
by starving a system of critical resources. 

DIRECTORY INDEXING 

Directory Indexing exploits insecure indexing, threatening a site’s data confidentiality. Site 
contents are indexed via a process that accesses files that are not supposed to be publicly 
accessible. Information is collected and stored by the indexing process and can later be 
retrieved by a determined attacker, typically, through a series of search engine queries. 
Directory Indexing has the potential to leak information about the existence of such files and 
their content. 
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DIRECTORY TRAVERSAL 


The Directory Traversal attack technique (aka Path Traversal) allows an attacker access to 
files, directories, and commands that potentially reside outside the root directory. An attacker 
may manipulate a URL in such a way that the application will execute or reveal the contents of 
arbitrary files anywhere on the server. Any device that exposes an HTTP-based interface is 
potentially vulnerable to Directory Traversal. 

FINGERPRINTING / FOOTPRINTING 

Fingerprinting or Footprinting is often an attacker’s first goal. They will accumulate as much 
information as possible including the target's platform, application software technology, 
backend database version, configuration, and possibly even their network architecture/ 
topology. Based on this information, the attacker can develop an accurate attack scenario to 
exploit any vulnerability in the software type/version being utilized by the target. 


FORMAT STRING ATTACK 

Format String Attacks alter the flow of an application by using string formatting library features 
to access other memory space. Vulnerabilities occur when user-supplied data is used directly 
as formatting string input for certain C/C++ functions (e.g. fprintf, printf, sprintf, setproctitle, 
syslog). 


HTTP REQUEST SMUGGLING 

HTTP Request Smuggling abuses the discrepancy in parsing non-RFC compliant HTTP 
requests between two HTTP devices - typically a front-end proxy or HTTP-enabled firewall 
and a back-end server - to smuggle a request to the second device through the first device. 
This technique enables an attacker to send one set of requests to the second device while 
the first device interacts on a different set of requests. This facilitates several possible exploits, 
such as partial cache poisoning, bypassing firewall protection and XSS. 

HTTP REQUEST SPLITTING 

HTTP Request Splitting forces the browser to send arbitrary HTTP requests. Once the victim’s 
browser is forced to load the attacker’s malicious HTML page, the attacker manipulates one of 
the browser’s functions to send two HTTP requests instead of one. 

HTTP RESPONSE SMUGGLING 

HTTP Response Smuggling uses an intermediary HTTP device that expects or allows a single 
response from the server to send two HTTP responses from a server to a client that expects or 
allows a single response from the server. 
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HTTP RESPONSE SPLITTING 


HTTP Response Splitting allows an attacker to manipulate the response received by a web 
browser. The attacker can send a single HTTP reguest that forces the web server to form an 
output stream which is then interpreted by the target as two HTTP responses instead of one, as 
is the normal case. 

IMPROPER FILESYSTEM PERMISSIONS 

Improper Filesystem Permissions are a threat to the confidentiality, integrity and availability 
of an application. The problem arises when incorrect filesystem permissions are set on files, 
folders, and symbolic links. When improper permissions are set, an attacker may be able to 
access restricted files or directories and modify or delete their contents. 

IMPROPER INPUT HANDLING 

Generally, the term input handling is used to describe functions like validation, sanitization, 
filtering, or encoding and/or decoding of input data. Improper Input Handling is a leading cause 
behind critical vulnerabilities that exist in systems and applications. 

IMPROPER OUTPUT HANDLING 

Improper Output Handling is a weakness in data generation that allows the attacker to modify 
the data sent to the client. 

IMPROPER PSEUDO-RANDOM NUMBER GENERATOR 

Insufficient randomness results when software generates predictable values when 
unpredictability is reguired. When a security mechanism relies on random, unpredictable 
values to restrict access to a sensitive resource, such as an initialization vector (IV), a seed for 
generating a cryptographic key, or a session ID, then use of insufficiently random numbers may 
allow an attacker to access the resource by guessing the value. The potential conseguences 
of using insufficiently random numbers are data theft or modification, account or system 
compromise, and loss of accountability (i.e., non-repudiation). 


INFORMATION LEAKAGE 

Information Leakage allows an application to reveal sensitive data, such as technical details of 
the application, environment, or user-specific data. Sensitive data may be used by an attacker 
to exploit the target application, its hosting network, or its users. 
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INSECURE INDEXING 


Information is collected and stored by the indexing process. Insecure Indexing allows this 
information to be retrieved by a determined attacker, typically through a series of gueries to 
the search engine. The attacker does not thwart the security model of the search engine; 
therefore, this attack is subtle and very hard to detect. It's not easy to distinguish the attacker's 
gueries from a legitimate user’s gueries. 

INSUFFICIENT ANTI-AUTOMATION 

Insufficient Anti-Automation occurs when an application permits an attacker to automate a 
process that was originally designed to be performed only in a manual fashion, e.g. registration 
for a site. 

INSUFFICIENT AUTHENTICATION 

Insufficient Authentication occurs when an application permits an attacker to access sensitive 
content or functionality without having to properly authenticate. For example, accessing admin 
controls by going to the /admin directory without having to log in. 


INSUFFICIENT AUTHORIZATION 

Insufficient Authorization occurs when an application fails to prevent unauthorized disclosure 
of data or a user is allowed to perform functions in a manner inconsistent with the permission 
policy. 

INSUFFICIENT COOKIE ACCESS CONTROL 

Insufficient Cookie Access Control occurs when cookie attributes such as “domain”, “path” and 
“secure” are not correctly utilized to limit access to cookies containing sensitive information. 
These attributes can be used by the user-agent when determining cookie access rights. 

INSUFFICIENT CROSSDOMAIN CONFIGURATION 

The crossdomain.xml file is used to determine from which resources a Flash application is 
allowed to access data. Insufficient Cross domain Configuration reflects a poorly configured 
Flash application that can be compromised to allow an attacker access to all the resources 
allowed in the cross-domain file. This error often occurs because a cross domain file makes 
use of wild-card notation. 

INSUFFICIENT PASSWORD AGING 

Insufficient Password Aging allows a user to maintain the same password for an extended 
length of time, increasing the risk of password-based attacks. 
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INSUFFICIENT PASSWORD RECOVERY 
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Insufficient Password Recovery occurs when an application permits an attacker to obtain, 
change or recover another user’s password without permission. This happens when the 
information required to validate a user's identity for recovery is either easily guessed or 
circumvented. Password recovery systems may be compromised through the use of brute 
force attacks, inherent system weaknesses, or easily guessed secret questions. 

INSUFFICIENT PASSWORD STRENGTH 

Insufficient Password Strength exists when a password policy does not aid the user in selecting 
a password that is less vulnerable to Brute Force attacks. 

INSUFFICIENT PROCESS VALIDATION 

Insufficient Process Validation occurs when an application fails to prevent an attacker from 
circumventing the intended flow or business logic of the application. 


INSUFFICIENT SESSION EXPIRATION 

Insufficient Session Expiration occurs when an application permits an attacker to reuse old 
session credentials or session IDs for authorization. Insufficient Session Expiration exposes an 
application to attacks that steal or reuse a user’s session identifiers. 

INSUFFICIENT SESSION INVALIDATION 

A user should be able to invalidate a session simply by logging out. This error occurs when the 
application removes the session cookie but doesn’t invalidate the session. 

INTEGER OVERFLOWS 

Integer Overflow occurs when the result of an arithmetic operation such as multiplication or 
addition exceeds the maximum size of the integer type used to store it. Attackers can use 
these conditions to influence the value of variables in ways that the programmer did not intend. 

INVALID HTTP METHOD USAGE 

FITTP Methods can be used inappropriately and compromise the integrity of the application. 
For example, the GET method is not intended to contain sensitive information or change the 
site state. Doing so increases vulnerability to Cross Site Request Forgery, Information Leakage, 
and accidental damage by crawlers. 

LDAP INJECTION 

LDAP Injection uses the open standard Lightweight Directory Access Protocol (LDAP) to 
preform exploits similar to those used in SQL Injection. 
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MAIL COMMAND INJECTION 


Mail Command Injection is an attack technique used to exploit mail servers and webmai! 
applications that construct IMAP/SMTP statements from user-supplied input that is not properly 
sanitized. 


NON-HTTP ONLY SESSION COOKIE 

A session cookie value can be accessed and manipulated by malicious client-side Javascript. 
Setting the “HttpOnly” attribute instructs the User-Agent to restrict access to the cookie only 
for use with HTTP messages. 

NULL BYTE INJECTION 

Null Byte Injection is an active exploitation technique used to bypass sanity checking filters 
in infrastructure by adding URL-encoded null byte characters (i.e. %00, or 0x00 in hex) to the 
user-supplied data. 

OS COMMAND INJECTION 

OS Command Injection, aka OS Commanding, is an attack technique used for unauthorized 
execution of operating system commands. 


PATH TRAVERSAL 

(see Directory Traversal) 


PERSISTENT SESSION COOKIE 

This error occurs when cookies whose values contain sensitive data have a future expiration 
date and do not expire with the session. 


PERSONALLY IDENTIFIABLE INFORMATION 

Personally Identifiable Information (PII) is information that identifies a single person or can 
be used with other information sources to identify a single person. Examples of Pll include: 
name, age, birth date, birth place, credit card number, criminal record, driver’s license number, 
education history, genotype, social security number, race, place of residence, vehicle 
identification number, and work history. 

PREDICTABLE RESOURCE LOCATION 

Predictable Resource Location allows an attacker, by making educated guesses via brute 
forcing, to guess file and directory names not intended for public viewing. Brute forcing 
filenames is easy because files/paths often have common naming conventions and reside in 
standard locations. Predictable Resource Location is also known as Forced Browsing, Forceful 
Browsing, File Enumeration, or Directory Enumeration. 
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REMOTE FILE INCLUSION 


Remote File Inclusion (RFI) exploits dynamic file inclusion mechanisms in applications. When 
a user input specifies a file inclusion; the application can be tricked into including remote files 
with malicious code. 

ROUTING DETOUR 

Routing Detour is a type of ''man-in-the-middle” attack in which intermediaries can be injected 
or hijacked in order to route sensitive messages to an outside location in such a way that the 
receiving application is unaware that it has occurred. 

SERVER MISCONFIGURATION 

Configuration weaknesses found in servers and application servers can trivially allow abuse of 
default functionality. 

SESSION FIXATION 

Session Fixation is an attack that forces a user’s session ID to a known value. After a user’s 
session ID has been fixed, the attacker will wait for that user to login and use the predefined 
session ID value to assume the same online identity. Session Fixation provides a much wider 
window of opportunity than would be provided by stealing a user’s session ID after they have 
logged into an application. 

SESSION / CREDENTIAL PREDICTION 

Session or Credential Prediction (aka Session Flijacking) is a method of hijacking or 
impersonating an authorized application user by deducing or guessing the unigue value that 
identifies a particular session or user. This can allow attackers to issue site reguests with the 
compromised user’s privileges. 


SOAP ARRAY ABUSE 

In XML SOAP Array Abuse, a service that expects an array can become the target of an XML 
DoS attack by forcing the SOAP server to build a huge array in the machine’s memory, thus 
inflicting a DoS condition on the machine due to the memory pre-allocation. 

SQL INJECTION 

SQL Injection exploits applications that construct SQL statements from user-supplied input. 
When successful, the attacker is able to execute arbitrary SQL statements against the 
database. 
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SSI INJECTION 


Server-Side Include Injection is a server-side exploit that allows an attacker to send code to 
an application to be executed later, locally by the server. SSI Injection exploits an application's 
failure to sanitize user-supplied data before inserting the data into a server-side interpreted 
HTML file. 

UNPATCHED LIBRARY 

All software components, runtime environments, platforms, and libraries need to be kept up to 
the very latest version of security fixes, to avoid exploits written specifically against known out- 
of-date library vulnerabilities. 

UNSECURED SESSION COOKIE 

If a session cookie does not have the secure attribute enabled, it is not encrypted between the 
client and the server. This means the cookie is exposed to theft. 

URL REDIRECTOR ABUSE 

URL redirectors can be abused to cause an attacker's URL to appear to be endorsed by the 
legitimate site, tricking victims into believing that they are navigating to a site other than the 
true destination. (See Content Spoofing) 


WEAK CIPHER STRENGTH 

In the Weak Cipher Strength vulnerability, the application's server allows the use of weak SSL/ 
TLS ciphers which are typically weaker than 128 bits and do not use signed certificates (e.g. 
SHA-1 hash). 

WEAK PASSWORD RECOVERY VALIDATION 

An application permits an attacker to illegally obtain, change or recover another user's 
password because the information reguired to validate a user's identity for password 
recovery is either easily guessed or can be circumvented. Password recovery systems may 
be compromised through the use of brute force attacks, inherent system weaknesses, easily 
guessed or easily phished secret guestions. 


XML ATTRIBUTE BLOWUP 

XML Attribute Blowup takes advantage of some XML parsers' parsing process. The attacker 
provides a malicious XML document, which vulnerable XML parsers process inefficiently, 
resulting in severe CPU load. Many attributes are included in the same XML node, resulting in a 
denial of service condition. 
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XML ENTITY EXPANSION 
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XML Entity Expansion exploits a capability of XML Document Type Definitions that allows the 
creation of custom macros called "entities". By recursively defining a set of custom entities at 
the top of a document, an attacker can overwhelm parsers that attempt to completely resolve 
these entities, resulting in a denial of service condition. 

XML EXTERNAL ENTITIES 

An XML External Entities attack takes advantage of a feature of XML that allows you to build 
documents dynamically at the time of processing. It uses an XML message that can provide 
data explicitly or points to an URL where the data exists. In the attack external entities may 
replace the entity value with malicious data. Alternately, referrals may compromise the security 
of the data to which the server/XML application has access. 


XML INJECTION 

XML Injection manipulates or compromises the logic of an XML application or service. The 
injection of unintended XML content and/or structures into an XML message can alter the 
intended logic of the application. Furthermore, XML Injection can cause the insertion of 
malicious content into the resulting message/document. 


XPATH INJECTION 

XPath Injection exploits applications that construct XPath (XML Path Language) gueries from 
user-supplied input to guery or navigate XML documents. 

XQUERY INJECTION 

XQuery Injection is a variant of the classic SQL injection attack against the XML XQuery 
Language. XQuery Injection uses improperly validated data that is passed to XQuery 
commands. 
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ABOUT NOWSECURE 


NowSecure is the mobile app security software company that enterprises trust 
to continuously secure mobile applications. NowSecure provides coverage for 
all mobile apps, superior testing and analysis, and multiple delivery models for 
automated or analyst-driven products. NowSecure customers benefit by making 
their app security process significantly faster and their apps more secure. For 
more information about NowSecure, visit www.nowsecure.com. 


ABOUT COALFIRE 

Coalfire is the cybersecurity advisor that helps private and public sector 
organizations avert threats, close gaps, and effectively manage risk. By 
providing independent, tailored advice and services that span the cybersecurity 
lifecycle (Cyber Risk Services, Compliance Services, and Coalfire Labs), we help 
clients develop scalable programs that improve their security posture, achieve 
their business objectives, and fuel their continued success. 


ABOUT WHITEHAT SECURITY 

WhiteHat Security has been in the business of securing applications since 2001. 
In that time, we’ve seen applications evolve and become the driving force of 
the digital business, permeating every aspect of our lives. As a result, it’s more 
important than ever to ensure that security experts and software developers 
work hand-in-hand to secure the applications that drive our daily digital 
experiences. The WhiteHat Application Security Platform is a cloud service that 
allows organizations to bridge the gap between security and development to 
deliver secure applications at the speed of business. This innovative platform 
is one of the reasons why WhiteHat has won numerous awards and been 
recognized by Gartner as a Leader in application security testing four times in 
a row. The company is headguartered in San Jose, Calif., with regional offices 
across the U.S. and Europe. For more information on WhiteHat Security, please 
visit www.whitehatsec.com. 
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